IP networks enable broadcasting of conversational data (Voice Over IP, Content Sharing, Presence, Instant Messaging, etc.).
The designation H.323 covers a set of protocols for transmission of voice, image and data over IP (for more information, see the on-line encyclopedia Wikipedia). These protocols were developed by the ITU-T. They can be grouped into three categories: signaling, codec (coder-decoder) negotiation, and information transport.
The SIP is defined by the IETE in the document RFC 3261. This protocol makes it possible to set up, modify and terminate multimedia sessions in a network using the Internet Protocol. The SIP also allows event notification procedures and sending information outside the context of a session. It is widely used for instant messaging service commands. Thus in an SIP environment there exist different types of calls such as session set-up requests and requests exchanged outside of any dialogue.
These sophisticated session control protocols make use, in particular, of signaling messages, which are messages enabling a terminal to request a connection with another terminal, and messages signaling that a telephone line is busy, or that the called telephone is ringing, or that the telephone is connected to the network and may be contacted in such or such a manner.
The invention relates particularly (but not exclusively) to IP Multimedia Subsystem (IMS) infrastructures. The IMS is defined by the standards bodies 3GPP (3rd Generation Partnership Project) and TISPAN (Telecommunications and Internet Converged Services and Protocols for Advanced Networking). It is a network architecture introduced by the 3GPP for mobile networks, and then adopted by TISPAN for fixed networks. This architecture enables dynamic setting up and control of multimedia sessions between two clients and reservation of resources at the level of the multimedia stream transport network. It also manages the interaction of services. At present the IMS allows access to telephone, videophone, presence, and instant messaging services.
When a user wishes to obtain the benefit of services offered by an IP network such as those described above, they send network signaling messages that may in particular include various types of request.
First, the user must register with the network. If the network is unable to link this registration and a previous registration (for example following a network fault or the terminal being switched off for longer than a predetermined expiration period), the registration is considered as being an initial registration. After an initial registration, the user must periodically (for example every hour) send the network a request to confirm that they wish to maintain their registration; the time interval between two such requests is referred to as a registration refresh period.
Moreover, if the network uses the SIP, users may subscribe to certain services by sending a corresponding request. The service may be an event notification service; for example, if a user has a voicebox on the network, the user may request to receive a notification from the network each time that a message is stored in that voicebox. The service may equally be a presence notification service, and so on. Following the initial subscription request, the terminal must periodically send the network a request to renew its subscription; the time interval between two such requests is referred to as the subscription refresh period.
The various states of the terminal-network system requesting periodic refreshing are commonly referred to as soft-states.
The applicable standards require the terminals to manage timers enabling them to send these refresh requests (registration or subscription refresh) automatically. When a user is registered on the network from a terminal (whether this refers to an initial registration or a refresh), the network informs the terminal of the registration refresh period required by the network operator. After initially registering, a terminal may send one or more initial subscriptions (for example message posting notification or presence notification), either automatically and immediately after initial registration, or else following an action of the user at the interface of the terminal; for each (initial or refresh) subscription, the network indicates to the terminal the refresh period required by the managers of the network for this subscription.
In this context, during normal operation of the network, the network receives initial registration and initial subscription requests and also receives registration and subscription refresh requests as and when network users connect and then renew their registrations and their subscriptions after the respective refresh periods. The processing capacity of the nodes of the network is obviously intended to accommodate the corresponding request reception frequency, in particular as a function of the usual number of network users. In many circumstances, and in particular with so-called “always-on” networks and services, in normal operation, the reconnection rate, and thus the initial rate of registration and subscription, is particularly low.
However, particular problems arise in this framework in the event of a partial or total fault of the network. Following a fault, terminals that have not succeeded in renewing their registrations and subscriptions all seek to implement an initial registration followed by one or more initial subscriptions. The rate at which terminals seek to effect initial registration depends on the programming of the terminals. In many circumstances the terminals apply a time-out period that is potentially (and usually) much shorter than the registration refresh period, which leads to a high rate of registration attempts. In other circumstances it is an action of the user at the interface of the terminal that triggers the registration attempt. It should be noted that in all circumstances the duration of this time-out period is not indicated by the network because under the present assumption the part of the network necessary for the usual processing of registration is then down; this time-out period is therefore chosen by the terminal or by the user. The network must therefore accommodate an abnormally high influx of requests, and all the more so as the duration of the fault increases; after rebooting, the network is congested and often incapable of processing all these requests. Moreover, after a vast set of initial registration requests have been met, the network must accommodate a new influx of requests coming from the same terminals at the end of the registration refresh period.
Application PCT 2007/130922 in the name of AT&T Corp. discloses a method of controlling registration request traffic in a server in a communications network. That method comprises the following steps: blocking all the input links to the server from a port of the network associated with the registration request traffic; unblocking at least one of said input links to the server from that port of the network, following configuration of the server to process registration requests; and repeating the unblocking step over time until all the input links from this port of the network are unblocked. For the unblocking step, it is preferably determined whether the server is configured to process registration requests at a rate conforming to a measured capacity of the server. In other words, after a fault of the server, the registration traffic to that server is progressively unblocked as and when the server progressively recovers its registration request processing capacities.
Accordingly, in the prior art, on rebooting the network, the terminals send their respective registration requests slightly offset relative to each other; as a function of its capacity (which may vary from one node to another), each node of the network processes the first requests that it receives. This being so, the load level of the nodes of the network rapidly increases until an overload results. Under those conditions, one or more nodes of the network fail to respond to the terminals in time, which terminals then consider that their registration request has failed. The terminals finding that their request has not been responded to wait before resubmitting a registration request, for a period depending on their programming; if the new registration request from a terminal is also rejected, then before being able to resubmit a new request, the terminal must again wait a certain period depending on its programming, and this process continues until all terminals affected by the fault and seeking to be reconnected have been able to achieve this.
Numerous timing algorithms are known for use by a terminal that has suffered a fault during an initial registration or registration refresh attempt.
Accordingly, the LiveBox terminals supplied by France Telecom are at present programmed to attempt to register every four minutes.
The proposal posted on the IETF website (draft-ietf-sip-outbound-16#section-4.5) defines an algorithm in which the waiting time observed by the terminal depends not only on the registration refresh period but also on the number of consecutive registration faults (to be more precise, the time period is doubled each time that the terminal suffers a new fault in its registration attempt, provided that the registration refresh period is not exceeded).
Known fault management methods are far from optimum where the waiting time suffered by terminals is concerned. Indeed:
1) as explained above, they rely on previous programming of the terminals; the terminals used to access services offered by a network operator are not necessarily programmed by the operator concerned;
2) the waiting time is determined as a function of the necessity to avoid saturating the lowest-capacity node or link of the network, in case it is precisely that node/link that fails; however, if the fault affects only one node/link of the network, that node/link will generally have processing capacity that is greater than the minimum capacity, and terminals connected thereto could therefore in theory be able to benefit from a shorter waiting time;
3) the waiting time is determined as a function of a standard fault duration; consequently, users suffer an excessive waiting time if the fault is relatively short; and
4) there is no provision for distinguishing between the different types of request (registration, event notification subscription, presence notification subscription, and so on); consequently, the risk of congestion is evaluated as a function of all the requests that are sent after a reboot; there is a lower priority for the managers of the network to satisfy subscription requests than to enable registration of all users wishing to register; the waiting period before the initial registration succeeds is therefore longer than if different waiting times were assigned to each type of request as a function of a respective degree of priority.
Thus the document entitled “SIP: Session Initiation Protocol” by J. Rosenberg et al. (IETF document RFC 3261, June 2002) proposes a Retry-After procedure in which a service server that is overloaded responds to clients that sent it service requests, by sending messages indicating rejection of those requests and prompting each of those clients to send a new request after a standard waiting time. However, that Retry-After procedure does not eliminate the congestion phenomenon referred to above: it merely postpones it to a later time. Moreover, as mentioned in the paper by M. Boucadair, P. Morand, L. Borges, and M. Tomsu entitled “Enhancing the Serviceability and the Availability of IMS-Based Multimedia Services: Avoiding Core Service Faults” (The Second International Conference on Next Generation Mobile Applications, Services and Technologies, IEEE Piscataway, N.J. USA (2008), that Retry-After procedure has the drawback that it is the overloaded server itself that reports its overloaded state to the clients concerned, which merely aggravates this overloaded state.